This chapter discusses creating and managing virtual servers. Virtual servers provide data access to both CIFS and NFS clients.
In Chapter 9, you created virtual interfaces and configured the network ports. In Chapter 11, you created storage pools. Now, you are ready to create virtual servers. After creating the virtual servers, you bind the virtual interfaces to the virtual servers.
Use the vservers command node to work with virtual servers.
To create a virtual server, use the vservers servers new command. A virtual server name can be 1 to 32 characters long and can consist of letters, numerals, and the period and underscore characters. The name must start with a letter or numeral.
The vservers servers new command creates a virtual server and identifies its root virtual file system. The virtual server's attributes include its virtual server name and its minimum authentication level. See Chapter 16 for information about authentication.
The syntax of the command follows.
vservers servers new -vsname virtual_server_name -spdevid storage_pool_ID -spinauth {true | false} -floatingsuperuser {true | false} -minauth {none | cifs-ntlm | cifs-kerberos | nfs-kerberos} -rulesetname rule_set_name -virusscanrwvfs {true | false} -virusscanrovfs {true | false} -showspinshot {true | false} -restrictedacl {true | false}
The following example creates a virtual server named vs0 that is attached to a storage pool named sp0. The virtual server does not use SpinAuth or permit a floating superuser. The virtual server uses nfs-kerberos as its minimum authentication level. A rule set named default_rules is applied to the virtual server. By default, virus scanning is enabled on any read-write VFSs and disabled on any read-only VFSs created on the virtual server. Any .spinshot directories on the virtual server are visible to clients by default. CIFS ACLs are not disabled on new VFSs created on the virtual server.
spinserver::> vservers servers new -vsname vs0 -spdevid sp0 -spinauth false -floatingsuperuser false -minauth nfs-kerberos -rulesetname default_rules -virusscanrwvfs true -virusscanrovfs false -showspinshot true -restrictedacl false
To display general configuration information about all virtual servers or specific information about one virtual server, use the vservers servers show command. To display information about one virtual server, use the command with the -vsname parameter. To display configuration information about a list of virtual servers in the system, do not use the parameter. The command has the following syntax.
vservers servers show [-vsname virtual_server_name]
The following example shows the configuration information for all virtual servers in a cluster.
spinserver::> vservers servers show<
Name Network Interface Min Authentication
vs1 Server1:vif2, Server1:vif3 Kerberos
vs2 Server1:vif4 None
The following example shows the configuration information for a virtual server named vs0.
spinserver::> vservers servers show -vsname vs0 Name vs0 Storage Pool for Root VFS pool0 User Type for root FID NFS Domain of root FID example.com User of root FID 0 Group of root FID 0 Network Interfaces Server12:Data, Server:Data Virtual Server ID 15 Root VFS ID 5369 Status online (Data,Data) Enable SpinAuth false Enable Floating SuperUsers false Min Authentication nfs-kerberos Export Ruleset Name default_ruleset VirusScan for R-W VFS true VirusScan for R-O VFS true
To remove a virtual server from the network, use the vservers servers delete command. The syntax of the command follows.
vservers servers delete -vsname virtual_server_name
Note: Deleting a virtual server deletes all virtual file systems associated with that virtual server.
Note: If a CIFS virtual server or NFS server interface that is configured to use Kerberos is deleted, or is changed to use a different Service Principal Name (SPN), its original service principal is not automatically deleted from or disabled in the Kerberos realm. If you no longer need the service principal, it is recommended that you manually delete or disable the principal. This requires the Kerberos realm administrator's user name and password.
To ensure the clean deletion of a virtual server, it is recommended that you perform the following steps:
Disable SpinShots and mirror replications for all virtual file systems. See Section 13.2.11.11 for more information.
Delete all VFSs on the virtual server that is to be deleted. See Section 13.2.5 for details.
Delete the virtual server.
Re-enable SpinShots and mirror replications for all virtual file systems. See Section 13.2.11.11 for more information.
The following example deletes a virtual server named vs0.
spinserver::> vservers servers delete -vsname vs0
This section discusses binding a virtual interface to a virtual server and unbinding a virtual interface from a virtual server by using the vservers servers bindif and vservers servers unbindif commands, respectively.
When a virtual interface is bound to a virtual server, the virtual server is ready to serve NFS requests. If the minimum authentication level for the virtual server is nfs-kerberos, NFS requests fail until Kerberos is configured; if the minimum authentication level is none, requests can be served immediately. To enable the virtual server to serve CIFS requests, see Chapter 14.
To bind a virtual interface to a virtual server, use the vservers servers bindif command. The syntax of the command follows.
vservers servers bindif -ssid spinserver -vsname virtual_server_name -ifname interface_name
The following example identifies an interface named if0 on a SpinServer named Server1 and binds the virtual interface to a virtual server named vs0.
spinserver::> vservers servers bindif -ssid Server1 -ifname if0 -vsname vs0
To unbind a virtual interface from a virtual server, use the vservers servers unbindif command. The syntax of the command follows.
vservers servers unbindif -ssid spinserver -vsname virtual_server_name -ifname interface_name
The following example identifies an interface named if0 on a SpinServer named Server1 and unbinds the virtual interface from a virtual server named vs0:
spinserver::> vservers servers unbindif -ssid Server1 -ifname if0 -vsname vs0
This section discusses binding multiple virtual interfaces to a virtual server and unbinding multiple virtual interfaces from a virtual server by using the vservers servers online and vservers servers offline commands, respectively.
To unbind all virtual interfaces bound to a specific virtual server, use the vservers servers offline command. The command identifies a virtual server and takes down all virtual interfaces bound to it, thus making it inaccessible to NFS and CIFS clients. The syntax of the command follows.
vservers servers offline -vsname virtual_server_name
The following example unbinds all virtual interfaces from a virtual server named vs0.
spinserver::> vservers servers offline -vsname vs0
To bind multiple virtual interfaces to a specific virtual server, use the vservers servers online command. The command identifies a virtual server and binds multiple virtual interfaces to it. The syntax of the command follows.
vservers servers online -vsname virtual_server_name
The following example binds multiple virtual interfaces to a virtual server named vs0.
spinserver::> vservers servers online -vsname vs0
Use the vservers servers modify command to modify configuration information for a virtual server. See Chapter 16 for information about authentication. The syntax of the command follows.
vservers servers modify -vsname virtual_server_name -spinauth {true | false} -floatingsuperuser {true | false} -minauth {none | cifs-ntlm | cifs-kerberos | nfs-kerberos} -rulesetname rule_set_name -virusscanrwvfs {true | false} -virusscanrovfs {true | false} -showspinshot {true | false} -restrictedacl {true | false}
The following example modifies a virtual server named vs0.
spinserver::> vservers servers modify -vsname vs0 -spinauth false -floatingsuperuser true -minauth cifs-kerberos -rulesetname rs0 -virusscanrwvfs false -virusscanrovfs false -showspinshot false -restrictedacl true
It is recommended that the root VFS of each virtual server be mirrored for redundancy and backup. You can mirror the root VFS of a virtual server even if you do not have the optional SpinMirror software package. To mirror the root of a virtual server, use the vservers servers newrootmirror command. The syntax of the command follows.
vservers servers newrootmirror -vsname virtual_server_name -sinkvfs sink_VFS -sinksp sink_storage_pool
The following example mirrors a virtual server named vs0 to a VFS named vs0.mirror. The mirror VFS is located on a storage pool named sp1.
spinserver::> vservers servers newrootmirror -vsname vs0 -sinkvfs vs0.mirror -sinksp sp1
For information about recovering the root VFS of a virtual server in the event of a catastrophic disk failure, see Section 19.2.19.
Virtual server routes are static routes. When packets are sent and the destination IP address is not on the local subnet or network, a default IP address is used as the destination IP address. This default address is usually a router or firewall on the local network. The default IP address is used when no other IP address matches.
Before you add a static route to a virtual server, you must add a default gateway for the route to use.
Use the vservers servers adddefaultgateway command to add a default gateway for a static route on a virtual server. The command has the following syntax:
vservers servers adddefaultgateway -vsname virtual_server_name -gateway gateway_IP_address
The following command example adds the gateway IP address 10.1.1.104 to a virtual server named Server1vserver1.
spinserver::> vservers servers adddefaultgateway -vsname Server1vserver1 -gateway 10.1.1.104
Use the vservers servers addstaticroute command to create a route for a virtual server. The command has the following syntax:
vservers servers addstaticroute -vsname virtual_server_name -gateway gateway_IP_address -netaddress network_IP_address -netmask netmask -metric metric
The following command example adds a new static route to a virtual server named Server1vserver1. The route is defined with a gateway IP address of 10.1.1.104, a destination IP address of 10.1.1.14, a netmask of 255.255.255.0, and a metric of 1.
spinserver::> vservers servers addstaticroute -vsname Server1vserver1 -gateway 10.1.1.104 -netaddress 10.1.1.14 -netmask 255.255.255.0 -metric 1
Use the vservers routes show command to display route configuration information about all virtual servers or information about one virtual server.
To display route information about one route, use the command with the -vsname, -nexthop, -netnumber, and -netmask parameters. To display route configuration information about a list of all routes, do not use any parameters. The command displays the following information about the virtual server or servers:
Virtual server name
Default gateway address
Network address
Network mask
Metric
The syntax of the command follows.
vservers routes show [-vsname virtual_server_name -nexthop nexthop_IP_address -netnumber network_IP_address -netmask netmask]
The following example displays information about a virtual server named vs0 that has a next-hop IP address of 10.1.1.104, a network IP address of 10.2.2.0, and a netmask of 255.255.255.0.
spinserver::> vservers routes show -vsname vs0 -nexthop 10.1.1.104 -netnumber 10.2.2.0 -netmask 255.255.255.0
The vservers routes delete command identifies a virtual server and removes its route. The syntax of the command follows.
vservers routes delete -vsname virtual_server_name -nexthop nexthop_IP_address -netnumber network_IP_address -netmask netmask
The following example removes the route of a virtual server named vs0 that has a next-hop IP address of 10.1.1.104, a network IP address of 10.2.2.0, and a netmask of 255.255.255.0.
spinserver::> vservers routes delete -vsname vs0 -nexthop 10.1.1.104 -netnumber 10.2.2.0 -netmask 255.255.255.0
Copyright © 2004 Network Appliance, Inc.; copyright © 2003, 2004 Spinnaker Networks, LLC. All rights reserved. Specifications subject to change without notice.